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Sir: 

Applicants request a Pre- Appeal Brief Review of the rejections of claims 1-20, which are 
based on clear error of fact and omission of essential elements to establish a prima facie 
rejection. 

I. BASIC MISUNDERSTANDING/MISDESCRIPTION IN OFFICE ACTION 

The claim rejections and various comments provided by the Examiner reflect a basic 

misunderstanding or misdescription of expressly-recited claim elements. 

The analysis provided in the Office Action fails to consider, within the context of the 

other claim elements, that: 

• multiple instances of the same peripheral device are instantiated in a single chip design; 

• at least two of the instances within the same chip have different configurations from one 

another; and 

• the different configurations are selected at compile time without modification of the 

hardware description of the peripheral device. 
As a result, the Office Action attempts to combine references that fail to meet the plain 
language of Applicant's claims. 
A. Bowen 
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Bowen discloses taking C code and partitioning it into hardware and software 
components to make a solution. Paragraph [0011] discloses duplicating a function, wherein the 
same function is used multiple times (no differences in configuration). For example an ASIC/IC 
will use a NAND gate multiple times in a design. 

Page 3 of the Office Action states that features of Applicant's arguments, "RTL is coded 
in a way so that different configurations can be used in a single chip without modifying the RTL 
for each instance," are not in the claims. But this statement is merely an example application of 
claim 1 to an RTL type of a hardware description language. 

In general, Applicant does not follow why the Examiner refers to Bowen paragraphs 
0041, 009, 0036, 0138. They have some of the same terms like compile and configuration, but 
different things are going on. 

More specifically, the Office Action incorrectly suggests that Bowen discloses 

"configuring a function block to instantiate multiple instances of the peripheral device within the 

single chip, ... the hardware description having options associated with different configurations 

of the peripheral device . . . wherein the options are selected without modification to the 

hardware description " 

1. Options are Not Selectable Without Modification To The 
Hardware Description 

Bowen, states in [0036], "a hardware compiler for producing from those parts of the 
specification partitioned to hardware a register transfer level description for configuring 
configurable logic resources." 

The register transfer level description configures the configurable logic resources 
according to the input provided to the hardware compiler. The input provided to the hardware 
compiler contains a pre-defined configuration that is used for configuring the configurable logic 
resources, such as during synthesis at step 214 in Figure 2. The input itself is not configurable at 
compile time. Rather it is predetermined by the C code. Thus, a configuration change would 
require a change to the hardware description. 

The Examiner may be suggesting that the C-like input is equivalent to the claimed 
"hardware description". However, Bowen discloses creation of multiple RTL descriptions from 
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the C-like input (it is reusable), whereas, claim 1 allows creation of multiple configurations 
("uses") from the same hardware description (e.g., RTL). 

The Examiner refers to Bowen, paragraphs [0040-0041]. Paragraph [0040] talks about 
taking a behavioral description of the target electronic system and automatically partitioning the 
required functionality between hardware and software while being able to vary the parameters 
(size or power) of the hardware and/or software. Varying the parameters of the hardware or 
software effects the output (the desired netlist or register transfer level (RTL) description). That 
netlist or register transfer level description (with only a single configuration) is then used in their 
FPGA or ASIC [0042]. There is no teaching or suggestion of any further modifications to 
achoeve multiple configurations of that netlist or register transfer level description in the same 
FPGA or ASIC. 

Bowen Figure 2 shows a C-like input description producing an output "RTL description" 
(box 212). The "width adjustment" blocks [206] are before block 212 in the flow and therefore 
before the RTL description is created. This RTL description is then targeted to an FGPA/ASIC 
[0144, 0145]. Paragraph [0127] talks about estimating the speed of the hardware. 

Thus, it is incorrect to state that Bowen does discloses options selected at compile time 
"without modification to the hardware description". 

Further, the discussion of Figure 2 does not disclose using this RTL description multiple 

times in the same chip (FPGA/ASIC). Whereas, the present application discusses appljdng 

configuration options to the RTL description to have the same RTL description used multiple 

times on the same chip, where at least two instances have different configurations. 

2. Bowen Does Not Disclose Selecting Between the Options at 
Compile Time for Each Instantiation of the Peripheral Device 

The Office Action acknowledges that Bowen does not disclose "selecting between the 

options at compile time for each instance of the peripheral device such that at least two of the 
instances have different configurations from one another," as recited in claim 1. 



B. Duboc 

Doboc et al. generally discloses a way to take existing building blocks and user input to 

make RTL, reduce to gates, and make an integrated circuit. Duboc et al. does not disclose using 

the same building block more than once with different input from the user in the same IC. Duboc 

mentions reusable templates, but where in Duboc does it say the same template is used multiple 

times with different inputs (configurations) in the same DSP? 

1. Duboc et al. Fails to Disclose That Two Different Instantiations 
Can Have Two Different Configurations Selectable at Compile 
Time 

The Examiner refers to col. 5, line 54 to col. 6 line 2, but this paragraph does not say two 
custom DSPs (or customizable circuit blocks with different configurations) are produced in the 
same IC. Duboc simpy discloses that a custom DSP is produced (meaning one configuration). 

Col. 3, lines 7-15 do not say that different configurations are used in the same DSP 
integrated circuit that is produced. 

The Office Action incorrectly states Duboc et al. shows "selecting between the options at 
compile time for each instance of the peripheral device such that at least two of the instances 
have different configurations from one another," citing Duboc, col. 8, lines 33-39; col. 10, lines 
31-34. 

Column 8, lines 33-39 mentions using the GUI input to initiate generation of the IC 
design via selection of a "compile option" from the GUI window, resulting in the execution of a 
script engine that verifies parameters input by a user. 

In Duboc et al., the user configures the IC once. In the example described in column 6, 
lines 47-57, they are making one custom DSP IC. Looking at the options of Table 1, the user 
picks one Data Y ROM size to make this one custom DSP IC. The user does not run the GUI 
(or a template) twice to have two or more custom DSP configurations (different DSP instances) 
on one IC . Rather, the user runs through the GUI once and it configures the IC. 

For example, there is not an instance identifier in FIG. 6 (so as to independently configure 
different instances in different ways). The Y RAM and X RAM are not two different of the same 
RAM instances, but are tied together with the same configuration (their address space is divided). 
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"The Y data space, which is configurable by the user, can occupy the top 2, 4, 8 or 16K of the 
data space, with the remaining data addresses mapped to the X data space." (Col. 6, lines 47-57; 
see also , col. 9, lines 43-47). They are not separately configurable instances of the same 
peripheral device. 

In the present application, the same building block (peripheral) can be used twice in the 
same IC and have a different configuration. So, for example, the user could configure the Data Y 
ROM to be 2K in one custom DSP instance on the IC and the Data Y ROM to be 4K in 
another/different custom DSP instance on the same IC. 

Duboc et al. do not disclose that two different instances of the same peripheral device can 
have two different configurations selectable at compile time. 

In fact, Duboc et al. do not suggest that such a feature would be desirable or how such a 
feature could be accomplished. The disclosed GUI does not provide that structure or 
functionality. 

C. Yu 

Col. 3 line 18-35 refers to the use of flow straps, slot straps and pad straps in relation to 
power distribution and not in relation to a logic or functional change in the ASIC design. 
Whereas, Applicant's use is for a logic or functional change/selection in the RTL (in the ASIC) 
(selecting option at compile time by "tying strap pins to power or ground" in claim 4). 

An example would be selecting between little endian data format and big endian data 
format for a data bus. 

Accordingly, Applicants respectfully request that the claim rejections under §103 be 
withdrawn. 

Respectfully submitted, 

WESTMAN, CHAMPLIN & KELLY, P.A. 

Bv: /David D. Brush/ 

David D. Brush, Reg. No. 34,557 
900 Second Avenue South, Suite 1400 
Minneapolis, Minnesota 55402-3319 
Phone: (612) 334-3222 Fax: (612) 334-3312 



